Subject: Re: Electronic AP for DLSw Multicast Spec

From: David Bryant/HQ/3Com <[email-masked]>
Date: 10 Sep 96 11:15:01 EDT

Harry - comments below
  
>----- Previous Message ---------------------------------------------------- 
>
>
>
>To: aiw-siglets-dlsw-redist  @ 3mail.3com.com @ UGATE
>cc:  
>From: hsilvers @ baynetworks.com (Harry Silverstone) @ UGATE    
>Date: Wednesday  September 4, 1996 09:48 PM
>Subject: Re: Electronic AP for DLSw Multicast Spec
>----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>Hi,
>
> I have read over the document and just had a few minor comments 
>and a question.
>
>- In the section, LLC Overhead, the last paragraph/sentence refers to IPv6
>   which I was thinking should probably be removed or placed together 
>   with the comment on SNA/HPR.

The sub-section on LLC Overhead ends with indented paragraph.  This sub-section 
and the other text are all under the topic of "Scope".  And, thus the statement 
on IPV6 seems appropriately placed.   I think the right thing to do, would be 
to move the SNA/HPR note up to this section.  I suggest we address this in the 
next revision of the paper prior to granting Closed Pages.
>
> - In the section, Single session TCP connections, the piece "(whenever
>   required and possible)", I think should be removed to minimize 
>   misunderstandings. The following sentences explain what is being said.

I'm ambivalent on this suggestion and am willing to do what the others beleive 
is correct.  I suggest we leave this issue to the next AIW meeting and 
encorporate the appropriate change (if any) in the final document prior to 
granting CP. 

>
>   By the way, there is another section named simarily to this one;
>   Single session TCP/IP Connections.
>
Yes, one is a bullet headed paragraph and the other is a 'true section' of the 
document
>
> - For the User defined DLSw Multicast group range, I trust that no one
>   vendor can/should monopolize one of these addresses? Just asking..
>
The user defined range is actually intend to be use-specific to a network.  
Vendors should not be hard-coding these values into their implementations or 
they are likely to get into interoperability problems.  Much the same as most 
IP implementations do not hardcode their IP addresses.   Hope this clarifies...

> - Is there any special consideration needed for PU2.1? It;s connection
>   may start with XIDs and not Test frames. 
>
Granted the document does not completely describe every possible connection 
setup sequence.  This was not deemed necessary as RFC 1795 does a fairly good 
job of this.  The multicast specification simply changes these sequences to use 
multicast as the _ex portion of discovery and then sets up a TCP connection 
prior to the _cs exchanges.   Hence, T2.1 node support presents no special 
circumstances beyond the ones already addressed in RFC 1795.   Does this make 
sense to you?
>
> - typo in Retres section "doesnt not"
>
Thanks, found it and corrected it.
> That's it for me.
> ~harry

---

From: Harry Silverstone <[email-masked]>
Date: Sun, 15 Sep 1996 21:15:26 -0400 (EDT)

Hi Dave,

	Thanks for your responses. I have no problem with them and the 
minor issues can be discussed at the next meeting. 

	The only item I was not sure about was the PU2.1 issue. This is 
covered in RFC1795, but after reading it several times, it seems to me 
that the implementer can pretty much handle the _ex portion of the setup 
for PU2.1 as they see fit. I guess propegating this into this spec is ok
although in retrospect it would have been better to have had more 
details on it in RFC1795.

~harry

>setup sequence.  This was not deemed necessary as RFC 1795 does a fairly 
>good job of this.  The multicast specification simply changes these 
>sequences to use multicast as the _ex portion of discovery and then sets 
>up a TCP connection prior to the _cs exchanges.   Hence, T2.1 node 
>support presents no special circumstances beyond the ones already 
>addressed in RFC 1795.   Does this make sense to you?
>